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ABSTRACT 



A gaming system is provided including a central game 
processor, a plurality of master processing units and a 
plurality of slave terminals operable by players to play 
the game. The central game processor communicates 
with the master processing units and supplies the vari- 
ous games available in the system. The master process- 
ing units store and administer the games as they are 
played on the slave terminals connected to each respec- 
tive master processing unit. A preferred game includes 
a fixed pool of game plays and a predetermined number 
of winning plays within each pool. Each player, 
through his or her slave terminal, can purchase plays in 
each fixed pool stored in the master processing unit to 
which that terminal is coupled. When a particular pool 
is exhausted, for example, through the purchase of all 
plays, the central game processor provides another 
fixed pool of plays to that master processing unit to 
enable continuous play. 

18 Claims, 21 Drawing Sheets 
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or even require a degree of skill from a player. In the 
VIDEO GAMING SYSTEM WITH FIXED POOL OF prior paper lottery systems or video gambling ma- 
WINNING PLAYS AND GLOBAL POOL ACCESS chines, the player essentially competes against the ma- 
chine and has no indication that other players are also 
This application is a continuation-in-part of applica- 5 competing to win the same or different prizes, 
tion Ser. No. 07/801,801, filed Dec. 2, 1991, now aban- What is lacking, therefore, is a lottery game that 
doned, the contents of which are hereby incorporated would overcome the above disadvantages of the previ- 
by reference ' ous lottery systems and would provide the advantages 

This patent document makes reference to a micro- of the now popular video games. These advantages 
fiche appendix, which includes a listing of the object 10 include greater access to more players, ease ot opera- 
code version of the software for practicing one pres- tion and administration, and minimal overhead in the 
ently preferred embodiment of the invention. The mi- form of human administrators. Such a video lottery 
crofiche appendix includes two microfiche having a system would also provide a game where players could 
total of 192 frames. directly compete against each other and thus have an 

A portion of the disclosure of this patent document 15 impact on their chances of winning, 
contains material which is subject to copyright protec- One video lottery game is described in U.S. Fat. No. 
tion. The copyright owner has no objection to the fac- 4,652,998, but lacks this element of competition be- 
simile reproduction by any one of the patent disclosure, tween players. According to the patent, a pool of tickets 
as it appears in the Patent and Trademark Office patent is produced and divided into rnini-pools unong multiple 
files or records, but otherwise reserves all copy right 20 terminals operable by various players. Each mini-pool 
rights whatsoever includes a fixed ratio of winning tickets that are allo- 

cated from the greater pool. However, each player only 
FIELD OF THE INVENTION purchases plays from the respective mini-pool allocated 

This invention relates to video lottery games and to his terminal and gambles on the random nature of 
other video games of chance, and in particular, to a 25 prize distribution within that pool. Simultaneous corn- 
video earning system providing games including a fixed petition against other players is not provided 
pool of game plays and a predetermined number of If a degree of competition were provided to this 
winning plays within each pool. video lottery system, a level of slull and the thrill of 

competition with others, would advantageously be 
BACKGROUND OF THE INVENTION 30 added Competing with other players at the same, or 
Lottery games where a player purchases a printed even a remote, location adds an element of fun not - 
ticket and gambles on winning a prize or sum of money provided in the previous gaming systems described 
are known in the art. Lottery games of this type, how- above. 

ever, generally require little or no skill on the part of the SUMMARY OF THE INVENTION 

player to play the game. At most, some minimal physi- 35 . . . 

cal act may be required of the player to reveal a preor- In view of the above, a master processing unit is 
dained outcome included on the ticket. The outcome of provided that includes a memory device. The memory 
the ticket has likely been determined in advance of the device is employed to store a fixed pool of game plays, 
purchase, usually at the time the tickets are printed. In where each fixed pool of plays includes a predeter- 
these games a player can determine immediately 40 mined number of winning plays. Coupled to the master 
whether the ticket was a winning ticket by simply ex- processing unit are a plurality of slave terminals that 
amining the face of the ticket. communicate with the master processing unit Each 

Other lottery-type games that require additional, slave terminal also is equipped with a player-controlled 
non-skilled acts on the part of the player are also selection device employed to request game plays from 
known These games may involve the scratching of a 45 the fixed pool of game plays stored at the master pro- 
removable surface deposited on the face of the ticket in cessing unit. Play of the games progresses as each 
order to reveal whether the ticket constitutes a winning player purchases game plays through the slave termi- 
hand The information printed on the ticket will usually nals from the whole pool of game plays stored at the 
also indicate the amount of any prize won. In paper master processing unit until the fixed pool of game plays 
pull-tab versions of this type of lottery game, the player 50 is exhausted. 

may peal back or tear off a paper covering to determine In one aspect of the invention, a central game proces- 
if the ticket was a winner. Even this version of the sor is also provided, which generates and supplies the 
lottery ticket, however, lacks a sense of competition fixed pools of game plays to the master processing unit, 
between other players or any feeling that a player can The central game processor is coupled to the master 
affect the outcome of the game. 55 processing unit through a communication interface. In 

The recent proliferation of the video game has pro- another aspect of the invention, a plurality of master 
vided greater reach or marketability for such lottery or processing units are provided. Each master processing 
gambling devices. Video games of chance, such as unit is coupled to the central game processor, and each 
video poker or video black jack, are examples of such master processing unit communicates with a plurality of 
video gambling machines. These video games are very 60 slave terminals coupled to that master processing unit, 
accessible and can be installed in bingo parlors or gam- The preferred embodiments described below com- 
bling halls so that many players can play at one time. bine the advantages of the prior paper lottery systems 

Even where these video lottery games or gambling with the ease and popularity of the video game. As in 
devices have succeeded in attracting more players, they the paper lottery systems each player purchases a video 
also have lacked an element of competition whereby a 65 lottery play from a fixed pool of such plays. As ui the 
player can compete not simply against a machine, but paper lottery systems, each game play has a predeter- 
aeainst other players as well. Such competition would mined chance of winning. The video lottery system, 
provide an element of thrill to the known lottery game, however, has the advantage of continuously updatmg 
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each player on the chances of purchasing one of the FIG. 11 shows the memory logic, FIG. 12 shows sound 
remaining winning plays in the pool. Use of computers generation circuitry and FIGS. 13A and 13B together 
and video terminals also affords on-line competition illustrate the input/output interface; 
among the many players that can simultaneously play FIG. 14 is a preferred illustration of one display pro- 
the lottery games at the same or remote locations. 5 duced on a video monitor employed in the slave termi- 

In the preferred embodiment, many players are capa- nal shown in FIG. 8; 
ble of simultaneously competing against each other for FIG. 15 is subsequent display produced on the video 
a predetermined number of winning plays provided in a monitor of the slave terminal showing a preferred video 
fixed pool of lottery game plays. Such competition lottery ticket; 

urges players to race in order to purchase the remaining 10 FIG. 16 is further successive display of the video 
winning plays within each fixed pool of plays before lottery ticket shown in FIG. IS prior to being opened; 
none remain. An element of strategy and skill is thus FIG. 17 illustrates the video lottery ticket shown in 
introduced since a player may decide to wait for the FIG. 16 after being opened; 

odds of purchasing a winning play to increase by allow- FIG. 18 is a graphic depiction of the master/slave 
ing other competitors to purchase some of the remain- 15 communication files; and 

ing non-winning plays, thereby increasing the odds of FIG. 19 is a depiction of the globally accessible data 
purchasing a winning play at a later time. Displaying on structures employed in the gaming system shown in 
a continuous basis the number of remaining plays and FIG. 1. 

the number of winning plays already redeemed allows DETAILED DESCRIPTION OF THE 

each player to assess the risk in purchasing another play 20 PRESENTLY PREFERRED EMBODIMENTS 
or whether to cease playing untd a new game is initi- 
ated. Reference is now made to the drawings where like 

These and other features and advantages will be ap- elements are identified by like numerals throughout, 
parent upon consideration of the following detailed FIG. 1 shows a gaming system made according to a 
description of the presently preferred embodiments of 25 preferred embodiment of the invention, generally desig- 
the invention, taken in conjunction with the appended nated at 10. The gaming system 10 includes a central 
drawings. game processor 12, which controls and administers 

operation of the gaming system 10. Preferably, re- 

BRIEF DESCRIPTION OF THE DRAWINGS mQtely located from the game pTOCessOT i2 are 

FIG. 1 is a block diagram of one preferred gaming 30 multiple master processing units 14. In one embodiment 

system made according to the invention; of the invention, the master processing units 14 are 

FIG. 2 is a block diagram of one preferred central connected to the central game processor 12 employing 

game processor employed in the gaming system shown a telephone link. In this embodiment, up to sixteen tele- 

in FIG. 1; phone lines 18 are used to connect between modems 22 

FIG. 3 is a graphical depiction of the software archi- 35 provided with each master processing unit 14 and the 

tecture employed in the central game processor shown multiple-line modems 24 provided in the central game 

in FIG. 2; processor 12. 

FIG. 4 is a state diagram for an incoming call state A plurality of slave terminals 16 are in turn connected 

machine employed in the central game processor shown to each master processing unit 14. According to the 

in FIG. 3; 40 preferred embodiment, up to twenty slave terminals 16 

FIG. 5* is a block diagram of one preferred master can be configured to each master processing unit 14. In 

processing unit employed in the gaming system shown this embodiment, the slave terminals 16 are intercon- 

in FIG. 1; nected through a local area network (LAN) 20. The 

FIG. 6 is a graphical depiction of the software archi- local area network 20 also couples the slave terminals 

tecture employed in one preferred embodiment of a 45 16 to their respective master processing unit 14. 

master processing unit shown in FIG. 5; Although a preferred system configuration has been 

FIG. 7 is a flow chart of a preferred background described, it will be appreciated by those skilled in the 

processing routine shown in FIG. 6; art that a number of different system configurations are 

FIG. 8 is a block diagram of one preferred slave possible without departing from the spirit and scope of 

terminal employed in the gaming system shown in FIG. 50 the invention. As will be appreciated, the combination 

1; of components provided in the gaming system 10 com- 

FIG. 9 is one presently preferred flow chart of the prises an integrated computer system capable of operat- 

functions performed on the slave terminal shown in ing an electronic lottery/gambling system or other simi- 

FIG. 8, where FIG. 9A illustrates main execution flow lar games. Each component of the gaming system 10 

on the slave terminal, FIG. 9B illustrates flow of the 55 provides a specific function necessary to operation of 

play selection subroutine, FIG. 9C illustrates flow of the gaming system 10 as a whole. However, these func- 

the command response subroutine, FIG. 9D illustrates tions can be further distributed or combined among 

flow of the wager selection subroutine, FIG. 9E illus- other computer architectures. 

trates flow of the cash out subroutine, FIG. 9F illus- As will be described more fully below, each element 
trates flow of the transaction cancel subroutine, FIG. 60 of the system 10 (the central game processor 12, the 
9G illustrates flow of the open single tab or open all tabs master processing units 14, and the slave terminals 16) 
subroutine, FIG. 9H illustrates flow of the select ticket also executes one or more computer programs in order 
subroutine and FIG. 91 illustrates the wager deposit to perform their respective tasks. The preferred corn- 
subroutine; puter programs addressed below may also take on dif- 
FIGS. 10-13 are preferred circuit diagrams of a gen- 65 ferent forms without departing from the spirit and scope 
eral purpose input/output interface adapter employed of the invention. 

in the slave terminal shown in FIG. 8, where FIGS. The purpose of the central game processor 12 is two- 

10A and 10B together show signal decoding circuitry, fold: (1) the central game processor 12 electronically 
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generates each fixed pool of game plays provided on the the ability to handle "lotto" type games including a 

gaming system 10, and (2) serves as an interface to each million plays or more. 

master processing unit 14. The central game processor In the preferred embodiment, each master processing 

12 thus acts as a repository for, and coordinates the unit 14 can dispense up to twelve or more games simul- 

production of, graphic data and game play information. 5 taneously, and each slave terminal 16 is continuously 

The central game processor 12 supplies, or downloads, informed as to the amount of plays remaining in each 

the fixed pools of game plays to each master processing fi*ed pool of plays. As an added feature, if many slave 

unit 14, and also performs periodic audit and security terminals 16 are located in a single gambling hall or 

checks of the master processing units 14. casino, each slave terminal 16 will display to the : player 

Each master processing unit 14 also contributes a 10 the various events happening within _ the haB. An- 

unique function to the gaming system 10. The purpose nouncements regarding closing of, foe hall ^ ***** 

ofthemasterprccessmgunitsMisprimarilytomanage other player has won, enhances ; the feehn that each 

the game plays being requested at the slave terminals 16. P'*^ 15 competing agarnst a group of players and not 

The master processing units 14 administer the games as just agamst the machine itself. 

, . ■ , j , , . • ,„ ,2 t_ «t.« 15 The video pul -tab lottery games administered by the 

they are being played at the slave terminals 16. In the » P * * charac _ 

admmistration o the games, th^r ^smg^ « video VesenLion of a pull-tab ticket is 
14 provide audit information about each of the slave slave terminals 16 showing which corn- 
terminals 16 to the central game processor U The rf g ^ a ^ ^ 
master processing .unite 14 also handle the summation iq ^ ^ one of the ^ ^ of plays 
and termination of each player s game play by calculat- ded ^ processor 12 for each 
ing each player's winnmgs and providing the player game ^ £ am{n £ system 1Q ^ displays the 
with a receipt. t . video ticket both before and after it has been opened. 

The slave terminals 16 provide the player interface to Such display mustrates the ap p rop riate graphic symbols 
the gaming system 10. The purpose of each slave termi- 2J ^ either a winn ing 0 r losing play. A mecha- 
nal 16, therefore, is to handle and process game play ^ ^ ^ ov/s ^ player t0 manage his betting 
requests from each player. Each slave terminal 16 keeps wnile the game fe p i ayed j s jj^ prov ided. Fea- 
track of each player's winnings and serves as a reposi- tures of {his mechanism include facilities for crediting, 
tory for each player's wagers. As part of the player de biting, depositing and withdrawing wagers as re- 
interface, each slave terminal 16 detects if the game play 3Q quired by p ] ayer during play of the game, 
currently requested by a player constitutes a winning As ment j one d, software is employed throughout the 
play, and if so, displays to the player the amount won. gaming system 10 in order to provide the fixed pools of 

One objective of the presently preferred gaming sys- game ^ t0 coordinate the activities taking place 

tern 10 is to simulate, through a video game embodi- m tne gaming system 10. The central game processor 12 

ment, the action and play of a paper pull-tab lottery 35 mc i u des a program for generating the fixed pools of 

game. The gaming system 10, however, is also capable ga me plays for each game supplied in the gaming sys- 

of supplying a variety of other games including more tem jo, As pr0 vided in the paper pull-tab lottery games, 

sophisticated games. Examples of such games include f ue d pool of game plays includes a predetermined 

poker, slot machines, progressive games, Pai Gow, number of winning plays. This predetermined number 

black jack, keno, bingo, craps, roulette and Red Dog. 40 0 f winning plays is fixed at the generation of each pool 

According to the preferred embodiment of the inven- 0 f game p i ays . As a result, in a fixed pool of "x" game 
tion, several players are capable of participating and plays and "y" winning plays, there are x—y="z" game 
simultaneously playing the games provided by the gam- p i ays that do not constitute a winning hand. Software 
ing system 10. Each player participates by purchasing provided on the slave terminals 16 continuously indi- 
plays through a respective slave terminal 16. Each mas- 45 ca t es to each player the number of winning plays al- 
ter processing unit 14 maintains a fixed pool of game ready purchased from each fixed pool and thus provides 
plays supplied from the central game processor 12 to be an indication of the chances of purchasing a subsequent 
transmitted to the slave terminals 16. Thus, as in the winning play. 

paper pull-tab lottery games, each player has access to Software is also provided to configure and operate 

and can purchase plays from the entire fixed pool of 50 the components of the gaming system 10 to perform 

game plays stored at each master processing unit 14. their intended functions. The specific functions per- 

Through the use of a player-controlled selection device • formed by each of the components of the gaming sys- 

(e.g., pushbuttons or the like) a player can request and tem 10 is described in more detail below. A preferred 

purchase game plays and gamble on purchasing a win- listing of the object code for the software employed 

ning play. Each player's activities, therefore, bear a 55 with the gaming system 10 is provided in the microfiche 

direct result on the outcome of purchasing subsequent appendix. 

plays from the fixed pool of game plays stored at the Game Processor u 
master processing units 14. 

In the preferred embodiment, it is important that each Referring to FIG. 2, the central game processor 12 

game retain the play and feel of the paper pull-tab lot- 60 comprises a central computer 30. In the preferred em- 

tery games. Thus, each player is continuously alerted bodiment, the central computer 30 can be an IBM Per- 

regarding how many plays remain in each fixed pool. sonal Computer-AT (or the equivalent), including an 

The number of plays remaining need not be displayed as 80386 (or 80486) microprocessor 32 manufactured by 

a numeric count per se, but may appear visually as a Intel Corp., Santa Clara, Calif., which preferably oper- 

graphic representation. In a typical game to be played 65 ates at a thirty-three megahertz clock speed. Further 

on the gaming system, between 1200 and 4800 plays are provided on the central computer 30 is a hard disk drive 

included in each fixed pool of game plays. In an alter- 34 and random access memory (RAM) 36. In order to 

nate embodiment, however, the gaming system 10 has provide ample storage space for the software running 
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on the central game processor 12, preferred sizes for processor 12. For example, such software enables the 
these memory devices range from 80- to 100-megabytes central game processor 12 to transmit codes in order to 
for the hard disk-drive 34 and four megabytes for the communicate with each master processing unit 14. 
RAM 36_ These codes communicate instructions to the master 

To facilitate communication with the master process- 5 processing units 14 to cause information stored in the 
ing units 14, the central computer 30 also includes a master processing unit 14 to be transmitted to the cen- 
plurality of modems 24, or a multi-channel communica- tral game processor 12. The software also enables the 
tion card (not shown). To achieve the necessary data transmission of new game designs from the central 
throughput, the modem 24 preferably operates at 2400- game processor 12 to each master processing unit 14. 
baud or higher. To complete the architecture of the 10 Further, software is provided to poll each master pro- 
central game processor 12, the central computer 30 also cessing unit 14 in order to determine gaming patterns 
includes a video monitor 40 and an associated video and trends. 

graphics adapter (VGA) card 42, a keyboard 44, and a A graphical depiction of the software architecture for 
printer 46. the central game processor 12 is shown in FIG. 3. Both 

The central game processor 12 operates as the central 15 foreground 50 and background 52 tasks are performed 
or coordinating computer for the overall gaming system by the software operating on the central computer 30. 
10. One function of the central game processor 12 is to Foreground tasks 50 handle a menu-driven operator 
issue new fixed pools of game plays and new games to interface, which receives input from the system admin- 
each master processing unit 14 as they are needed. The istrator sitting at the video monitor 40 and keyboard 44. 
central game processor 12 thus keeps an adequate in- 20 Executing in the background is a routine for handling 
ventory of the games currently being offered, and en- incoming calls from the master processing units 14. 
sures that the system itself is operating properly. A Each call comes into the central computer 30 over a 
prime function of the central game processor 12, there- series of telephone lines 18 and is received by the plural- 
fore, is to communicate with each master processing ity of modems 24 included in the central game proces- 
unit 14 and to supply each master processing unit 14 25 sor 12. After the incoming call is processed by the com- 
with more pools or more games. munications software 54, the central game processor 12 

In the preferred embodiment of the invention, new must determine how to respond to the call. Provided in 
pools of game plays are entered by operators at the FIG. 4 is a state machine included in the central corn- 
central game processor 12. Operators simply key in data puter 30 that handles the incoming calls, 
from preexisting paper pull-tab lottery tickets into the 30 Processin Unit 14 

central computer 30. As will be described m more detail 

below, software running on the central computer 30 A preferred embodiment of one master processing 
converts the raw symbol and deal data entered by the unit 14 is shown in FIG. 5. In the preferred embodiment 
operators into several files to be used in the gaming shown in FIG. 5, each master processing unit 14 in- 
system 10. For example, one of such software programs 35 eludes a master computer 70. The master computer 70 is 
examines the data entered for each paper ticket and preferably an IBM Personal Computer AT-type corn- 
searches for winning symbol combinations. Winning puter, including an 80386 microprocessor 72 manufac- 
combinations are identified by the central computer 30, tured by Intel Corp., Santa Clara, Calif., and operated at 
which stores temporarily the amount won for that com- a clock speed of thirty-three megahertz. The master 
bination. When all combinations and directions (hori- 40 computer 70 also includes a hard disk memory 74 and 
zontally, vertically and diagonally) have been scanned on-board RAM 76. To satisfy the software needs of the 
and scored, the final amount won is appended to the master processing units 14, the hard disk memory 74 
ticket data (described in detail below) and stored in the should be at least 80-megabytes and the on-board RAM 
central computer 30. As is the case with most tickets, if 76 should include between two and four megabytes of 
no winning combinations are detected, the amount won 45 addressable space. 

will be zero and stored as such with the ticket data. Further provided on the master computer 70 is a 
When all tickets have been entered and scanned by the 2400- to 9600-baud modem 22 for communication with 
central computer 30, the pool of tickets is stored for the central game processor 12, and a LAN interface 80 
subsequent transfer upon request from the master pro- for communication with the plurality of slave terminals 
cessing units 14. 50 16 coupled to the master processing units 14. The LAN 

In order to perform its tasks, the central game proces- interface 80 on the master processing unit 14 is thus 
sor 12 should preferably receive and log update requests ' similar to that provided in each slave terminal 16 (de- 
from each master processing unit 14. Conversely, the scribed below). A video monitor 82 and associated 
central game processor 12 is able to poll each master video graphics adapter card 84 are also included in the 
processing unit 14 to request status about the specific 55 master computer 70, as is a keyboard 86. The master 
local area network 20 configuration and the individual computer 70 may also include an optional printer 88. 
status of each slave terminal 16 connected thereto. The Each master processing unit 14 has two primary re- 
central game processor 12 thus becomes both the logi- sponsibilities: (1) to perform certain requests initiated 
cal and physical link between all of the master process- from the central game processor 12, and (2) to maintain 
ing units 14. A detailed description of the communica- 60 continuous communication with each slave terminal 16. 
tion protocol between the master game processors 14 As part of its first task, each master processing unit 14 
and the respective slave terminals 16 is provided below responds to requests initiated by the central game pro- 
in connection with FIG. 18. cessor 12. In the preferred embodiment, each master 

In the preferred embodiment of the invention, the processing unit 14 stores at least one fixed pool of game 
central game processor 12 comprises a personal com- 65 plays received from the central game processor 12. 
puter or minicomputer. The functions described above, Each master processing unit 14 further includes pass- 
as well as additional functions, are thus contained in words for four levels of access to the master processing 
software programs that execute on the central game units 14. These passwords are distributed to the various 
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levels of master administrators operating each master nals 16. Information from the slave terminals 16 is re- 
processing unit 14. One password is preferably em- ceived by the master processing unit 14 over its local 
ployed to start the game, and at least one other pass- area network 20. Similarly, game plays from the fixed 
word is required to change or display any network pool of game plays stored in a database 64 located on 
parameters ~ 5 thc master processing unit 14 are communicated over 

As part of its second responsibility, each master pro- the local area network 20 to the slave terminals 16. A 
cessing unit 14 is prepared to respond to requests from flow chart of the background processing 62 performed 
the slave terminals 16 configured on its local area net- on the master processing unit 14 appears in FIG. 7. 
work 20 (FIG. 1). A primary function of the master As shown in FIG. 7, at steps 90, 91, the background 
processing units 14 is to download game plays requested 10 loop normally reads and displays the time of day until a 
from the slave terminals 16 from the fixed pool of game command (ticket validation, audit, etc.) or response is 
plays stored in the master processing unit 14. Each received from a slave terminal 16. If a command or 
master processing unit 14 can also request the status of response has taken place, the master processing unit 14 
each slave terminal 16, generate and send a validation must determine how to react. As shown at steps 92, 93, 
code to any slave terminal 16, and broadcast messages 15 if a specific command is pendmg at the master process- 
to all slave terminals 16 connected to its local area net- ing unit 14, the command is sent to the requesting slave 
work 20 terminal 16 over the local area network 20. If not, trie 

The master processing unit 14 also has the ability to master processing unit 14 may poll the slave terminal 
view network activity in order to determine the status for its status at step 94. 

of a particular game being played at the various slave 20 After transmitting a command, the master processing 
terminals 16. In a preferred embodiment, the master unit 14 determines at steps 97, 98 whether the slave 
processing unit 14 displays to a master administrator terminal 16 has responded appropriately. If so, the mas- 
(bingo hall or gambling operator) an inventory report of ter processing unit 14 processes the response at step 95. 
the games currently offered on the gaming system 10. After completion of these tasks, the background routme 
The master processing unit 14 also displays the status of 25 relinquishes control of the master processor at step 96. 
its network, i.e., the status of each slave terminal 16 In order to access any of the remaining features pro- 
connected to the master processing unit 14, and pro- vided at each master processing unit 14 a second or 
vides an audit report regarding each particular slave third password may be required as explained above, 
terminal 16. The master processing unit 14 also displays Examples of the remaining features provided by the 
the status of each pool, which includes an indication of 30 master processing units 14 include selection of game 
the amount of plays remaining. A list is also provided of • options, record keeping and audit-oriented tasks. A 
game options, which are selectable at each master pro- detailed description of these functions is provided m 
cessing unit 14 by the master administrator. more detail below. 

As play on the gaming system 10 commences, the m SJave Xermina i 16 

main duty of the master processing unit 14 is to poll the 35 

slave terminals 16, one-by-one, to provide their status. FIG. 8 is a block diagram of one preferred embodi- 
The collection of status information is done such that ment of a slave terminal 16. At the heart of each slave 
each player will not notice a delay in response time terminal 16 is a slave computer 100. The slave computer 
from his or her slave terminal 16. The status of each 100 can be in one preferred embodiment an IBM Per- 
slave terminal 16 may be one of five states: (1) enabled, 40 sonal Computer, or a minicomputer or personal^ com- 
(2) disabled, (3) out of service, (4) not responding, and puter of similar function. The slave computer 100 thus 
(5) operational preferably includes a microprocessor 106 and a video 

Each master processing unit 14 also includes facilities graphics adaptor 108, which connects to a color moni- 
to shut down its local area network 20 in an orderly tor 110. In the preferred embodiment of the invention, 
fashion, and then power down its branch of the gaming 45 the slave computer microprocessor 106 is an 80286 (or 
system 10 Thus, each master processing unit 14 of the 80386) microprocessor manufactured by Intel Corp., 
gaming system 10 configures its local area network 20 Santa Clara, Calif., which preferably operates at a 
on a case-by-case basis. twenty megahertz clock speed. „ . 

A graphical depiction of the software architecture for Included in the slave computer 100 is a LAN inter- 
the master processing units 14 is provided in FIG. 6. 50 face 102 for communication to the master processing 
Each master processing unit 14 preferably performs . unit 14. The LAN interface 102 couples to a LAN con- 
internal diagnostics upon power-up. After the diagnos- nector 104 provided on the slave terminal 16, which ties 
tics are completed, a password or log-on code is re- each slave terminal 16 to its respective local area net- 
quired from the master administrator to start the games, work 20 (FIG. 1). The LAN connector 104 preferably 
as described above. After the proper log-on has been 55 comprises a BNC T-type connector for configuration to 
initiated, the display appearing at each master process- the local area network 20. In the slave computer 100, 
ing unit 14 continuously shows the status of each slave the LAN interface 102 uses interrupts IRQ3 or 
terminal 16 connected to its local area network 20. "IRQ15" to communicate with the microprocessor 106, 

As shown in FIG 6, foreground 60 and back ground and preferably is ROM-base selectable. A programma- 
62 processing is performed at the master processing 60 ble read only memory (PROM) used I to boot start the 
units 14. In the foreground, a menu-driven user inter- slave terminal 16 is also included m the LAN interface 
face is provided to handle communication to and from 102. 

the master administrator. Information received from the The color monitor 110 included m each slave termi- 
master administrator is communicated from an operator nal 16 is an essential element to the player interface of 
display 66 and handled by the foreground processing 65 the gaining system 10. In the preferred embodiment, 
routines ~ each color monitor 110 displays the video version of the 

Background processing 62 on the master processing paper pull-tab lottery ticket that comprises a preferred 
unit 14 handles messages received from the slave termi- game play in the gaming system 10. Preferably, the 
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color monitor 110 produces a 640x480x256 non-inter- terminals 16. At steps 210, 212 of FIG. 9A execution 

laced display. The smaller the dot pitch of the color begins and all variables are initialized. At step 214 the 

monitor 110, the more accurate the display; however, pro gram checks for a power failure, and if power has 

extremely high graphics resolution is not a critical item failed, at step 216 corrective action is taken and flow 

of the slave terminal 16. The video graphics adaptor 108 5 proceeds at step 218 to pick up where execution left off 

consequently provides the same 640x480x256 non- (see FIG. 9B below). At step 224 the program deter- 

interlaced display, and is preferably capable of display- mines if player credits are available from either wager 

ing up to 256 colors simultaneously. The video graphics deposits or a player's winnings. If there are no credits 

adaptor 108 also includes approximately one megabyte available, then the particular slave terminal 16 is not 

of on-board memory (not shown) to achieve the dis- 10 being used and the slave terminal 16 is idle. While not in 

plays contemplated for use in the preferred gaming use, the slave terminal 16 executes a demonstration loop 

system 10. The memory provides storage for video at steps 220, 222 and displays an "attract" screen (dis- 

graphics software drivers and other video graphics cussed below). At step 222 the program checks for any 

processing elements. communication sent from the master processing unit 14. 

The Bios type employed in the slave terminals 16 may 15 jf cre dits are available at step 224, the program pro- 
be any of the commercially available Bios types, so long ceed& ^tj, p ] ay 0 f t j, e game. At step 226, a "select 
as a keyboard (not shown) provided on the slave termi- va i„ e » screen is displayed and at step 228 the program 
nal 16 can be disabled through software. The slave waits for p i ayer entry . while waiting, the program 
computer 100 should also preferably include at least again checks at step 230 for communications from the 
512-kilobytes of random access memory to accomplish 20 master processin g un j t 14. Player entry can come in the 
its many tasks in a reasonable time. form of ^ of the player controlled pushbuttons 128 

As shown in FIG. 8, a general purpose input-output provided on the slave terminal cabinet 115 (FIG. 8). A 

(I/O) interface adapter 116 is also coupled to the micro- preferred set of pushbuttons 128 is illustrated in FIG. 

processor 106 The general purpose I/O mterface 9A) which correspond to wager denomination pushbut- 

™£™ T 116 P refe / abl y res ' d ^ s at m ,f mory ^ dress 25 tons 234, 236, 238 (Group 1) or play action buttons 

D800H. In the preferred embodiment, the general pur- 242-250 (Group 2) 

pose I/O interface adapter 116 comprises a custom J w tQ FJG 9B shou]d a , d 

printed circuit board wmch is descnbed m greater pWbutton, the program first determines 

detail below in connection with FIGS. 10-13. The gen- , «. « j-f. - :i.ut„ „. „.„_ -, C a 

eral purpose I/O interface adapter 116 connects to a 30 whefter enough player cnditt a« a^ib^at rt^ 2Wk 

speaker 120 located on the exterior of the slave terminal If not ' the , P ro S ram branches back at „ s e P 256 10 . Wa ? f ° r 
cabinet 115. The speaker 120 projects the various correct player mput^If enough credits are avanable to 
sounds used during the play of the garnes on the gaming ste P 258 the P^gram mitiates a ticket 

system 10. These founds are stored and generated by a W*. to *f "f* Processing unit 14. Upon receipt 
sound generator chip located in the general purpose 35 of the .cketjdata from the master processmg unit 14, the 
I/O interface adapter 116 (described below). Connected P la V er s credits are decremented to reflect the wager 
to the general purpose I/O interface adaptor 116 is a amount at ste P 260 ^ **«"■«* rec ?' ve D d f™ m * e ma f" 
battery backed RAM 118. A door 122 is also provided ter processing .taut 14 is loaded into the RAM 118 on the 
in the slave computer cabinet 115 to allow operator or slav f termnal 16 (FIG. 8). At step 264, the program 
service access to the general purpose I/O interface 40 Splays an unopened video ticket and waits for new 
adaptor 116. player mput at step 266. _ _ 

Configured to the general purpose I/O interface FIG. 9C illustrates the flow of communication be- 
adaptor 116 are the necessary electro-mechanical de- tween the sIave tenmnals 16 and the master processing 
vices required to implement the gaming system 10 of the 14 As mentioned above, the slave terminal penodi- 

invention. In the preferred embodiment, these elements 45 cally checks to deterrmne if there is a command pendmg 
include a wager accepter, preferably in the form of a bill fr ° m the master processing unit (step 268). If not, pro- 
accepter 124 and a coin acceptor 126, a plurality of gram flow returns to the mam slave routine at step 270. 
player-controlled selection devices in the form of push- If a command is pendmg from the master processing 
buttons 128, and indicator lights 130. The front switch ««it 14, a response is required by the slave terminal 16. 
panel of the slave terminal 16 may include as many as 50 In the preferred embodiment of the invention shown in 
ten such player controlled pushbuttons 128. The bill FIG. 9C, a variety of slave terminal responses 272 are 
acceptor 124 located on the slave terminal 16 is prefera- ' available for the various commands sent by the master 
bly capable of accepting denominations from $1 to $20. processing units 14 (described below). 
Also provided in the slave terminal 16, are five 16-bit Further player input provided at step 228 of FIG. 9A 
expansion slots (not shown) for future expansion or 55 is illustrated in FIGS. 9D-9H. FIG. 9D illustrates pro- 
customization, a hopper 132 to retain wagers and at gram flow upon selection of one of the wager denomi- 
least four digital meters 134 to display scores, etc. nation (Group 1) pushbuttons 234, 236, 238. At step 274 

Each slave terminal 16 also preferably provides a the wagered amount is set, and at steps 276, 278 the 
validation ticket to the players after the player is program awaits selection of one of the play action 
through playing. The slave computer 100 also includes 60 (Group 2) pushbuttons 242-250. Should the player se- 
a printer 112 to provide a hard copy printout of its lect the Cash Out push-button, the program then deter- 
status. The interface between the microprocessor 106 mines if the player has any credits to redeem (step 278). 
and the printer 112 is accomplished through a printer If not, at step 280 the program returns to wait for valid 
interface card 114 as shown in FIG. 8. input. If credits are available to be redeemed, at step 282 

Referring to FIGS. 9A-9I, a flow chart of the func- 65 the program requests a validation number from the 
tions performed by the slave terminal 16 is provided. master processing unit 14. Upon receipt of the valida- 
The functions identified in FIGS. 9A-9I are preferably tion number, at step 284 a validation ticket is printed 
implemented through software residing at the slave and at step 286 the player's credits are cleared. The 
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program then returns to the demonstration mode at step As can be seen, in the preferred embodiment shown 

28 8 in FIGS. 10-13 many integrated circuits are employed 

Referring to FIG. 9F, the player may select the Can- to perform various functions in the general purpose I/O 

eel pushbutton. If so, and if a ticket face is being dis- interface adapter 116. To meet the preferred response 

played at step 290, the program branches to again dis- 5 times for the gaming system 10, therefore, these inte- 

play the "select value" screen at step 292. If not, at step grated circuits should possess no more than an 80- or 

294 the program returns to the main program flow. 100-nanosecond propagation delay in order to P'oyidea 

Should the player select the Open Tab X or Open All zero-wait state environment for the gaming system 10. 
pushbutton, program flow continues at step 246 shown jy Gaming System 10 Operation 

in FIG. 9G. At step 296 the appropriate tab or tabs are 10 tn , . , 

opened and the "underlying" ticket symbols are dis- I» the gammg system 10, the *™ "°P£ 

phTyed. The program then determines if all tabs are ates » Allows Preferably, the slave termnurf 16 fin* 

v y . . m % 0 | Tf _„ t „ ttm iin the nrnirram runs a set of internal diagnostics each time it is turned 
open at step 298. If not, at step 230 the program slave ^ m Js 

branches backfor more player input (i.e. open thenext ^ ^ ^ 

tab). If all tabs are open the p ayer credits are mere- processing ^14 preferably shows a graphic 

mented at step 302 ifa winning «*«™J?£f** map of to slave nftwork during operation of the gaming 
wmrung ticket has been purchased ^ step 304 a con- ^ . f & ^ u ^ ^ ^ mtemal 

gratulatory display is also presented. The program then ^ ti the network ma ^ show that s i aV e ter- 

returns at step 306 to await new player input 2Q ^ Jfi m « enabled » but "NOT RESPOND- 

Should the player depress the Select pushbutton, at ft fe ^ master administrator > s task t0 determine 

step 308 of FIG. 9H the program displays the face of the what tQ do tQ resolve the slave ^mimal 16 error, such 

next available ticket in the fixed pool of game plays. At ^ lacin a cal) for service to a local distributor or 

step 310, the program waits for new player input. service representative. When the slave terminal 16 

Referring to FIG. 91, a wager subroutine is illus- 2J $ ^ diagn0SticS) the mas ter processing 

trated. At step 312, an interrupt is generated to the ^ u wiu show ^ s , ave te rminal ig ^ "ON-LINE", 
microprocessor 106 (FIG. 8) and at step 314 the player's ^ s , ave terminal ig next displays an introductory 

credits are increased according to the wager amount display on the color monitor 110 to attract attention and 

deposited by the player into the slave terminal 16. At pi ayers . This attract screen includes demonstration 

step 316, the program then returns to the main program 3Q g ra pbj cs 0 f game operation in a manner known in the 

flow of FIG. 9A. ar t, a depiction of a front view of a slave terminal • 

Referring now to FIGS. 10-13, detailed schematic ca binet 115, including a display of the attract screen 

diagrams of the general purpose I/O interface adapter appearing on the color monitor 110, is shown in FIG. 

116 are provided. As seen in FIGS. 10-13, a plurality of j4 

programmable array logic devices (PAL's) 140 are em- 35 Preferably located at the top or bottom of the display 

ployed throughout the general purpose I/O interface j s a fj e id 150 use d to broadcast messages received from 

adapter 116. The PAL's 140 comprise much of the inter- the master processing units 14. As described more fully 

connect circuitry and help reduce the chip count on this below, one of the tasks of the master processing units 14 

printed circuit board. In one preferred embodiment of ^ to broadcast to each slave terminal 16 messages re- 

the invention, the PAL's 140 are programmed using the 40 garding the game pool currently being played on that 

TANGO-PLD (Version 1.11) PAL assembler. Copies master processing unit 14. These messages are em- 

of the prograrnming equations for the PAL's 140 em- ployed to convey information regarding other players' 

ployed in the general purpose I/O interface adapter 116 betting to create an atmosphere of competition over the 

are provided in the Appendix. gaming system 10. An example of these messages in- 

In addition to the PAL's 140, a plurality of buffers/- 45 elude: "Another winning play has been purchased on 

drivers 142 are provided throughout the circuitry machine 6!!!"; or "Congratulations to the player on 

shown in FIGS. 10-13. These buffers/drivers 142 help machine 2, who just selected a $250 winning play!!!". In 

boost, latch and clock signals as they propagate through a preferred embodiment, these messages are displayed 

the general purpose I/O interface adapter 116. As 0 n each slave terminal 16 regardless of whether it is 
shown in FIG. 11, a RAM 144 is also provided in the 50 sitting idle or is in the middle of a play, 
general purpose I/O interface adapter 116. In preferred As shown in FIG. 14, a "CREDITS" field 162 is 

embodiment, the RAM 144 is 32 kilobytes in size. preferably located in the upper left hand corner of the 

Referring to FIG. 12, a sound generator integrated display appearing on the color monitor 110. An indica- 

circuit (IC) 146 is included in the general purpose I/O tion of the number of tickets remaining in the pool cur- 
interface adapter 116. The sound generator IC 146 pro- 55 rently being played is also provided in the upper right 

duces and stores the sounds projected from the speaker hand corner of the display. In the preferred gaming 

120 (FIG. 8) employed with the gaming system 10. As system 10, each time a player deposits a wager in the 

those skilled in the art will appreciate, such sounds can appropriate slot on the slave terminal 16, the CREDITS 
take on many different forms depending on the games field 162 is updated. Deposit of the wager also corn- 
being played on the gaming system 10 and personal 60 mences play on the gaming system 10. 
tastes " " Referring to FIG. 15, after the placement of a wager 

Referring to FIG 13B, a number of Darlington Drive the display changes to show the face of a video ticket 
current boosters 148 are also provided in the general 164 (corresponding to the face of a paper pull-tab ticket) 
purpose I/O interface adaptor 116. The Darlington on the left hand side of the display screen 165. As play 
current boosters 148 are used in the preferred embodi- 65 progresses, if the player next depresses the Play push- 
ment to drive the indicator lights 130, the bill accepter button 166 (FIG. 14), the slave termmai 16 will elec- 
124 coin accepter 126 and the digital meters 134 ap- ironically request a play from the pool of remaining 
pearing on the slave terminal 16 (see FIG. 8). plays stored at the master processing unit 14. In re- 
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sponse, the master processing unit 14 will transmit to 
the slave terminal 16 a packet of ticket data representing 
the purchased play. Each play corresponds to a video 
pull-tab ticket in the preferred embodiment of the in- 
vention. The data received is stored on the slave termi- 
nal 16 to be interpreted after the player depresses the 
next appropriate pushbutton. 

In the preferred embodiment of the master processing 
unit 14 employing the 80286 microprocessor, the worst 



ploying the Ethernet 802.3 protocol. To communicate, 
each side (i.e., each slave terminal 16 or master process- 
ing unit 14) must lock a record transmitted over the 
network 20 before attempting to read or write it. The 
recipient must then unlock the record when it is fin- 
ished. Communication between the slave terminals 16 
and the master processing units 14 is thus controlled 
through software running on each component. 
A listing of the definitions of the programs used in a 



case response time for the slave terminal 16 to receive a 10 preferred embodiment of the gaming system 10 appears 



below. The files designated are stored in either the 
central game processor 12, the master processing units 
14 or the slave terminals 16 depending upon the file type 
and its usage. 



play will be approximately 0.83 seconds. However, the 
average response time is likely to be 0.42 seconds de- 
pending on the number of players currently participat- 
ing. When the play is received at the slave terminal 16, 
the CREDITS field 162 is decremented to reflect the 15 
wager amount. 

The graphic depiction appearing on the screen of the 
color monitor 110 is then updated to the configuration 
shown in FIG. 16. The video ticket 164 appearing on 
the left hand side of the display screen 165 does not 20 
change between FIGS. 15 and 16; however, the box 
appearing on the right side of the display screen 165 is 
presented to simulate and display the closed pull-tabs 
170 of a paper pull-tab lottery ticket. The player then 
has at a time, or opening all of the pull-tabs 170 at once. 25 
In order to further simulate a paper pull-tab lottery 
ticket, the slave terminal 16 will produce a ripping 
sound as the screen displays the pull-tabs 170 being 

slowly opened (FIG. 17). As shown in FIG. 17, the p our fj es ^ ai s0 provided for each pool of game 
pull-tabs 170 will remain open as if they were peeled 30 tickets, which identify the game serial number and a 





Configuration Files 


SITE.CFG 


site specific information: name, 




phone number, etc. 


USER.CFG 


users and passwords 


OPTION.CFG 


configurable options 


SLAVE.CFG 


state of slave terminals (enabled or 




disabled) 


GAME. MAP 


relates pools to active games 




Report Files 


EVENT.LOG 


sequential record of key system 




events 


STATUS.RPT 


current system status 


AUDITix RPT 


status of all the slave terminals 16 



away from the video ticket 164 appearing on the display 
screen 165. 

After the pull-tabs 170 have been opened, the slave 
terminal 16 scans the data received from the master 
processing unit 14 with each video ticket 164 to deter- 35 
mine if the ticket 164 includes any winning combina- 
tions. In the preferred embodiment, since all tickets 164 
have previously been tabulated and identified by the 
central game processor 12, the slave terminal 16 simply formuuw.DEF 
scans the data received from the master processing unit 40 formaxm.dst 
14 to detect the presence of a winning combination. 
Such combination is identified by the central game 
processor 12 at the time tickets are input into the system 
(described above) by preferably setting a bit in the video 
ticket data packet sent to the slave terminal 16. Upon 45 
detection of the set bit, the slave terminal knows a win- 
ning combination has been purchased. If a winning 
combination is detected, the slave terminal 16 reads and 
displays the amount won in the lower portion of the 
display screen 165 as illustrated in FIG. 17. Any amount 50 
won is added to the CREDITS field 162 appearing on . 
the screen. After a short delay, the screen reverts back 
to the display shown in FIG. 14. This sequence of play, 
and the associated screen displays, continues until a 
player exhausts all of his or her credits, or until the 55 
player depresses the Cash Out pushbutton 172 (FIG. 
14). 

After the Cash Out pushbutton 172 has been de- 
pressed by a player, a validation ticket is printed with a 



description of the aspects of each game. These game 
files are set forth below. 



FORM«out.CFG 
FORMxxxx.HDR 



VALIDATE.REC 



VALIDATE. STT 



AUDIT.FTG 



CMDRSP.FTG 



GAMHDrU.PTG 



SYSMSG.FTG 



Game Files 

game configuration information, 
(i.e., rows, size, etc.) 
header file for no. of winning ticket 
combinations and amounts 
ticket definitions and symbols 
ticket distribution (i.e., how many 
of what type) 
Validation Files 

SO validation records (assigned and 
free) 

validation state (most recent seq # & 
date) 

Other Files 

File of 20 records containing audit 
information about each slave terminal 
16. 

File of 20 records containing com- 
mand/response block for each slave 
terminal 16. 

File of the Game Header, where jui = 01- 
12 depending on game number. 
File of messages for slave terminal 
16 and master processing unit 14. 
Each record is 80 bytes long, and is 
indexed by record number. 



In the preferred embodiment of the invention, soft- 
ware is provided at the central game processor 12 to 
validation number received from the master processing 60 convert the raw symbol data entered by the operators 



unit 14. In a preferred embodiment, the player may then 
take this validation ticket to a cashier in order to redeem 
any prizes or money won. 

V. System Implementation 

In a preferred embodiment of the invention, the local 
area network 20 connecting the slave terminals 16 to the 
master processing unit 14 is an Ethernet network em- 
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into the video ticket data mentioned above. For exam- 
ple, one file, CVTPTI.EXE, is employed to convert the 
raw symbol data into the four game files identified 
above. 

Set forth in Table 1 is a preferred configuration of an 
audit record prepared by the master processing unit 14 
to be completed for each of the slave terminals 16. The 
record appearing in Table 1 represents 1 of 20 such 
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sequential records arranged in the file AUDIT.PTG for 
each slave terminal 16 coupled to the LAN 20. 

TABLE 1 



GAMHDRxx.PTG, where 
number. 



"xx" represents the game 



Byte 



00 

01 

02 

03 

04 

05 

06 

07 

08 

09 

OA 

0B 

0C 

0D 

0E 

OF 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

1A 

IB 

1C 

ID 

IE 

IF 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

2A 

2B 

2C 

2D 

2E 

2F 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

2A 

2B 

2C 

2D 

2E 

2F 



Description 



MM (BCD) 
DD (BCD) 
YY (BCD) 
HH (BCD) 
MM (BCD) 
SS (BCD) 
Total Tickets Played 
Total Tickets Played 
Total Tickets Played 
Total Coins In 
Total Coins In 
Total Coins In 
Total Bills In/4 
Total Bills In/4 
Total Bills In/4 
Total Bet 
Total Bet 
Total Bet 
Total Won 
Total Won 
Total Won 
Total Cashed Out 
Total Cashed Out 
Total Cashed Out 



MM (BCD) 
DD (BCD) 
YY (BCD) 
HH (BCD) 
MM (BCD) 
SS (BCD) 
Total Tickets Played 
Total Tickets Played 
Total Tickets Played 
Total Coins In 
Total Coins In 
Total Coins In 
Total Bills In/4 
Total Bills In/4 
Total Bills In/4 
Total Bet 
Total Bet 
Total Bet 
Total Won 
Total Won 
Total Won 
Total Cashed Out 
Total Cashed Out 
Total Cashed Out 



Date 

Initialized 
Gregorian Format 
Time 
Initialized 
(24 Hr Format) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 
Date 

Initialized 
Gregorian Format 
Time 
Initialized 
(24 Hr Format) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 
(BCD Digits 5,4) 
(BCD Digits 3,2) 
(BCD Digits 1,0) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 

(Reserved) 



M 
A 
S 
T 
E 
R 



M 

E 
T 
E 
R 



P 

E 
R 

O 
D 



M 
E 
T 
E 
R 



TABLE 2 



Byte 



Description 



10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



00 
01 
02 
03 
04 
05 
06 
07 
08 
09 
OA 
OB 
0C 
0D 
0E 
OF 
10 
11 



FORM NUMBER (BCD) 
FORM NUMBER (BCD) 
SERIAL # (BCD) 
SERIAL # (BCD) 
SERIAL # (BCD) 
SERIAL # (BCD) 



FORM NUMBER (BCD) 
FORM NUMBER (BCD) 
SERIAL # (BCD) 
SERIAL # (BCD) 
SERIAL # (BCD) 
SERIAL # (BCD) 



CREDITS PER TICKET (1-4) HEX 
(Reserved) 
(Reserved) 
(Reserved) 
(Reserved) 
(Reserved) 
(Reserved) 
(Reserved) 
(Reserved) 
(Reserved) 

# of Symbols/Window (BCD) # of Windows (BCD) 
# of Total Symbols used in the Game (Hex) 



Set forth in Table 2 is a sample game file used in the 
preferred embodiment of the gaming system 10. Each 60 
game file contains the necessary parameters to define 
each game. The first symbol (Symbol #1) provide din 
the game file is the symbol that appears in the upper 
left-hand corner of the video ticket 164 displayed on 
each color monitor 110 (see FIGS. 15-17). In the pre- 
ferred embodiment, the gaming system 10 also includes 
headers for each game offered on the system. Each 
game header is stored in a separate file called 
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The form number and serial number for each game 
appears at the top of each header file at locations 00H 
and 01H. The form number for each game is preferably 
three digits; the unused bit in the file is thus zero-filled. 
For example, Form #720 would be entered as "0720". 
The serial number is handled in the same manner. 

Referring to FIG. 18, the four files listed above under 
the Other Files designation consist of files used for 
communication between the master processing units 14 
and the slave terminals 16. As shown in FIG. 18, the file 
CMDRSP.PTG 180 comprises a record of the com- 
mands and responses received or transmitted by each 
slave terminal 16. Each slave terminal 16 reads com- 
mands written to this file by the master processing unit 
14, and each slave terminal 16 writes its response to this 
file to be read by the master processing unit 14. The 
location of this file in the master processing units 14 is 
identified in FIG. 19 (Command Queues 208). A de- 
tailed description of the preferred commands and re- 
sponses employed on the gaming system 10 is provided 
below. 

The file AUDIT.PTG 182 comprises a record of the 
status for each slave terminal 16. Slave terminal 16 
status is written to the file by each slave terminal 16 on 
command from the master processing unit 14. The in- 
formation stored in this file is processed by the master 
processing units 14 to generate the audit report for the 
system adrninistrator. 

As shown in FIG. 18, both the SYSMSG.PTG 184 
file and the G AMHDRxx. PTG 186 file are files em- 
ployed in a unidirectional manner; data is written to 
each by the master processing unit 14 to be read by the 
slave terminal 16. In the file SYSMSG.PTG 184, system 
messages are stored to be broadcast on each slave termi- 
nal 16 as defined by the master administrator. Each 
slave terminal 16 also reads the particular 
GAMHDRxx.PTG file 186 necessary to configure the 
slave terminal 16 for the particular game to be played. 
The master processing unit 14 writes the 
GAMHDRxx.PTG files 186, one for each game sup- 
ported, when the game is activated. 

Referring to FIG. 19, a number of globally accessible 
data structures are also provided in the gaming system 
10. These structures also correspond to the Other Files 
listed above and are located in the memory map of each 
master processing unit 14. The Game Map structure 190 
consists of three records which relate games in the 
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inventory stored at each master processing unit 14 to signed a number from one to six. Further examples of 
currently active games. The Game Configuration data the substance of such messages include: (1) "The facility 
structure 192 also consists of three records that provide is going to close"; (2) broadcast information about a 
detailed information about the active games on the sys- winner; (3) "Ticket level low"; (4) a particular game is 
tem. The Game Configuration structure 192 thus in- 5 now closed; and (5) "We are closed . . . Goodnight", 
eludes the game name, form number, size, number of The master administrator controls distribution of these 
rows and columns, symbols, number of tickets remain- messages to each of the slave terminals 16 via the files 
ing in the pool, the shuffled pool itself, and ticket defini- defined above. 

tions. There is also a Network State structure 194 that As stated, the master administrator also has access to 
stores a representation of the state of each master pro- 10 some options that may be turned on or off as the admin- 
cessing unit's 14 local area network 20. istrator desires. Options accessible to the administrator 

Data structures are also provided for validation and are defined in the Master Options data structure 204 
user identification. Two structures define the Validation (FIG. 19), and include for example: (1) whether the 
Numbers 196 supplied when a player cashes out, as well slave terminal 16 displays to the player the number of 
as the Validation State 198. The Validation Numbers 15 plays remaining in a game; (2) whether winning ticket 
196 consist of 1000 records comprising the outstanding amounts are broadcast to other slave terminals 16; (3) 
validation numbers provided to players who have the amount of time in which to display the closing an- 
cashed out, as well as the remaining unassigned num- noun cement; (4) whether the low ticket level message 
hers. The Validation State 198 lists the next sequence should be broadcast, and if so, at what percentage of 
number for a validation ticket and a modified julian 20 plays remaining; and (5) whether the optional printer 88 
date. The User file 200 consists of ten records including ^ attached to the master computer 70 (see FIG. 5). 
the names, passwords and access levels of each adminis- Depending on whether the optional printer 88 is 
trator, as well as unassigned numbers. A data structure coupled to the master computer 70, the master adminis- 
also exists for the Time and Date 202. trator is capable of sending reports both to the printer 

Other structures in the gaming system 10 include a 25 gg or t0 tne monitor 82 (FIG. 5). Audit information is 
file for master processing unit 14 options, the state of fjj. st displayed or printed for each slave terminal 16, and 
each slave terminal 16 and command queues. The Mas- tnen a summa ry of all slave terminal 16 information is 
ter Option file 204 contains configurable options such as provided. This information can also be communicated 
show cards, broadcast winners and shut down informa- over trie modem 24 to the central game processor 12 in 
tion. The Slave State records 206 describe the status of 30 a pre f e rred embodiment. Table 3 contains a general 
each slave terminal 16 with respect to the command/re- listing of the information contained in the audit reports, 
sponse cycle. The Command Queue 208 is a storage 

record for slave terminal commands including audit, tatjt c ■» 

shut down, reset and broadcast information, and is used TABLE 3 

in conjunction with the CMDRSP.PTG file 180 shown 35 
in FIG. 18. 

In one preferred embodiment of the gaming system 
10, a menu of commands/options is provided at the 
master processing units 14. After the gaining system 10 
is initialized and the master administrator has completed 40 

logging onto the master processing unit 14, a menu Information included for each slave terminal 16 in- 
routine is executed. The main options available on the eludes the date and time the slave terminal 16 was ini- 
menu include validation/administration commands, tialized, the number of video tickets 164 played, the 
reporting functions and system service options. Com- number of coins and bills received, the total amount bet 
mands displayed on the menu correspond to the pro- 45 and won, and the total amount cashed out. 
grams and data files described above. The master administrator can preferably disable a 

In one embodiment, the game symbols displayed on game from the master processing unit 14 at any time. In 
the back of a video ticket 164 are slightly larger than addition, the master administrator can queue games to 
those displayed on the front of the ticket 164. As a be automatically loaded after the game pool currently 
result, two sets of symbol definitions are required for 50 played is exhausted. If games are queued in this manner, 
each game. In this embodiment, a file labeled the succeeding game will share the same form number 
FORMxxxx.FAC includes the graphics for the ticket ' as the game currently being played so that new game 
face, and a file labeled FORMxxxx.BAC contains the symbols need not be down-loaded to the slave terminal 
graphics for the back of the video ticket 164. A third 16 while the game is in progress. Thus, the master ad- 
file, FORMxxxx.PAL, includes palette definitions. 55 ministrator is capable of observing the status of the 

As mentioned, the color monitor 110 displays the games being played, and also which games remain in the 
number of tickets 164 remaining in each game being inventory of games stored at the master processing units 
played in a field 168 appearing on slave terminal color 14. Games listed in the inventory are, therefore, turned 
monitor 110 (FIG. 14). For each play that turns up a on and made active by the master administrator, 
winner, therefore, a message in the form "WIN SXXX" 60 The following tasks can be performed on-line at the 
appears on each color monitor 110. The game's six digit master processing units 14, while games are being 
serial number also appears on the bottom of each dis- played: (1) display game status; (2) display slave ter- 
play. minal/network status; (3) disable a game; (4) display 

An editing mechanism is preferably provided to inventory; (5) edit system messages; and (6) queue like 
allow up to six messages to be communicated between 65 forms. The following tasks are performed off-line: 1) 
each master processing unit 14 and the slave terminals display/change system options/flags and send broad- 
16 as defined in connection with the CMDRSP.PTG cast information; and (2) set up service/site information 
file 180. To ease implementation, each message is as- within a file. 



Game ID/Sena! No. 


Each Slave Terminal 16 


Serial Number 


Game ID or Serial Number 


Plays Remaining 


Starting Plays 


Date/Time of Report 


Plays Remaining 


Amount Left to Win 


Audit Information 
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Table 4 includes a preferred listing of the commands 
used in a preferred embodiment of the gaming system 
10. As described above, commands are transmitted from 
the master processing units 14 to the slave terminals 16. 
Responses are transmitted from the slave terminals 16 to 
the master processing units 14. 

TABLE 4 



2. Request a Validation Number; 

3. Know the total play count of a pool (BEGIN); or 

4. Know the current play count of a pool (LEFT). 

5. Transmit status. 



Command 



Definition 



10 



15 



CMD 01 Transmit Status/Tickets Total & Remaining 

CMD 02 Receive Ticket/Symbol Definitions 

CMD 03 Receive Validation # and SSS Amount 

CMD 04 Receive Network Broadcast Information 

CMD 05 Power Down Sequence 

CMD 06 Copy Slave Audit Info, to AUDIT record 

CMD 07 Requested Ticket Cannot Be Sent-Pool 
Empty 

CMD 08 Initialize All Meters 

CMD 09 Initialize Period Meters only 

CMD 10 Request Denied 

CMD 1 1 Force Down Sequence 

CMD 12 Restart Unit 



Responses to the commands identified in Table 4 are 
set forth in Table 5. Responses to Commands #2, #3, 
#4 and #5 should be Response #1 indicated in Table 5. 
The response to Command #1 can be any of the re- 25 
sponses appearing in Table 5. 

TABLE 5 
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Data Packet 




UNIT NUMBER 


CMD byte 1 


Transmit Status 


Command 01 n 






Response O0H 


CMD byte 3 




Game Number (01-OC) 


data 04 


OOHex - FFHex 


Total plays byte 1 


data 05 




To al plays byte 2 


data 06 


w 


Total plays byte 3 


data 07 




Total plays byte 4 


data 08 




Total plays byte 5 


data 09 




Total plays byte 6 


data OA 




Plays remaining byte 1 


data 0B 




Plays remaining byte 2 


data 0C 




Plays remaining byte 3 


data 0D 




Plays remaining byte 4 


dataOE 




Plays remaining byte 5 


data OF 




Plays remaining byte 6 
1 


data 10H 




1 

00 


data 53H 



For example, if Game #5 started with 3600 plays, and 
had 290 left, the data bytes would be filled out as fol- 
lows: 



Response 



Definition 



RESP 01 All is well 

RESP 02 Send a new ticket 

RESP 03 Send a validation Number 

RESP 04 Winning Ticket Just Displayed 

RESP 05 Power down acknowledge 

RESP 06 Send temporary validation number 
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Command #4 is the broadcast message command 
initiated at the master processing unit 14. The contents 
of the message to be displayed will have been previ- 
ously defined and stored on the master processing unit 
14 (in file SYSMSG.PTG 184). Command #5 is a pow- 40 
er-down sequence command. In response to Command 
#5, the slave terminals 16 should display an appropriate 
message to the player, such as "PLEASE CASH OUT 
... WE ARE SHUTTING DOWN IN ( ) MINUTES 
. . ." After Command #5 has been sent, no more credits 45 
can be purchased. When the cash out transaction is 
completed, the slave terminals 16 should be placed out 
of service, i.e., not allowing any additional plays to be 
purchased or money to be inserted. 

As mentioned, each master processing unit 14 re- 50 
quests status information from each slave terminal 16. 
Command #6 has been reserved for this purpose. In 
response to Command #6, the slave terminals 16 update 
the appropriate record in the AUDIT. PTG 182 file, and 
conclude with Response #1. The master processing unit 55 
14 will then collate this data and display or print it for 
the system administrator. 

Commands #7 and #8, when issued by the master 
processing unit 14, cause the slave terminals 16 to clear 
the appropriate software meters 64. A detailed descrip- 60 
tion of the commands and data communicated over the 
local area network 20, and the responses received, ap- 
pears below. 

A. Command #1: Update Your Status 65 

This command from the master processing unit 14 
allows the slave terminal 16 to: 
1. Request a video ticket; 





05 Hex 


(Game #) 


data 01 


OOHex - FFHex 


10 Hex 


(Start ) 


data 02 




0E Hex 




data 03 




00 




data 04 




00 




data 05 




00 




data 06 




00 




data 07 




01 Hex 


(Plays 


data 08 




22 Hex 


left) 


data 09 




00 




data 04 




00 




data 05 




00 




date 06 




1 

00 




data 53 



B. Response #1: All is well 

This response indicates to the master processing unit 
14 that the slave terminal 16 is operating normally, that 
a play has not been requested, and that a validation 
number is not required at this time. This is the correct 
response if: 

1. A video ticket has been successfully received; 

2. A validation number has been successfully re- 
ceived; 

3. Meters have been successfully cleared; 

4. The requested message has been displayed; or 

5. Audit information is ready. 

Normally, for the program to transmit this response, it 
will be in response to Command #1. 



Data Packet 




Unit Number 


CMD byte 1 




Command 


CMD byte 2 


All Is Well: 


Response 01 


CMD byte 3 



data 04 
data 05 
data 06 
data 07 
date 08 
data 09 
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Data Packet 



data OA 
data OB 
dataOC 
data OD 
dataOE 
data OF 
data 010 

dataS3H 



C. Command #2: Receive a Video Ticket/Symbol 
Definition 



10 



15 



This command from the master processing unit 14 
results when a slave terminal 16 has previously trans- 
mitted the "SEND A TICKET" (Response #2) re- 
sponse. It allows the slave terminal 16 to receive and 
evaluate a new play from the requested pool of game 2Q 
plays. The Tabs and symbol windows (Wind) are de- 
fined as follows: 



24 



-continued 


Data Packet 


Tab 3 Window # 03 


data 11 


Tab 3 Window # 04 


data 12 


Tab 3 Window # 05 


data 13 


Tab 4 Window # 01 


data 14 


Tab 4 Window # 02 


data 15 


Tab 4 Window # 03 


data 16 


Tab 4 Window # 04 


data 17 


Tab 4 Window # 05 


data 18 


Tab 5 Window # 01 


date 19 


Tab 5 Window § 02 


data 1A 


Tab 5 Window # 03 


data IB 


Tab 5 Window # 04 


data 1C 


Tab S Window # 05 


data ID 


Win Amount xx 


data IF 


Win Amount xx 


data 20 


1 

00 


data 53 



Symbols are ordered 


as follows: 






sym 05 


TAB A 


sym 01 


sym 02 


sym 03 


sym 04 


TAB B 


sym 06 


sym 07 


sym 08 


sym 09 


sym 10 


TAB C 


sym 11 


sym 12 


sym 13 


sym 14 


sym 15 


TAB D 


sym 16 


sym 17 


sym 18 


sym 19 


sym 20 


TAB E 


sym 21 


sym 22 


sym 23 


sym 24 


sym 25 



Tabl 


Tabl 


Tabl 


Tabl 


Tabl 


Wind 1 


Wind2 


Wind3 


Wind4 


WindS 


Tab2 


Tab2 


Tab2 


Tab2 


Tab2 


Wind 1 


Wind2 


Wind3 


Wind4 


Wind5 


Tab3 


Tab3 


Tab3 


Tab3 


Tab3 


Wind 1 


Wind2 


Wind3 


Wind4 


Wind5 


Tab4 


Tab4 


Tab4 


Tao4 


Tab4 


Wind 1 


wWind2 


Wind3 


Wind4 


Wind5 


Tab5 


Tab5 


Tab5 


Tab5 


Tab5 


Wind 1 


Wind2 


Wind3 


Wind4 


Wind5 



In a pool having five total symbols, and a game with 
25 three tabs only, assume the following correlation has 
been defined: 



1 = heart 2 = club 3 = spade 4 — diamond 5 = crown 
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If the video ticket to be displayed looks like this: 



heart 
club 
club 



club 
heart 
spade 



heart 
spade 
diamond 



And the game number is 11: 



If not window or tab exists for a particular game, the 
data should be set to 00, e.g., a 3-tab ticket with only 3 w 
windows per tab. 



Data Packet 




Unit Number 


CMD byte 1 


Receive a Play 


Command 02 


CMD byte 2 


Response 


CMD byte 3 




Game Number (01 -OC) 


data 



Tab 1 Window # 01 
Tab 1 Window # 02 
Tab 1 Window # 03 
Tab 1 Window # 04 
Tab 1 Window # 05 
Tab 2 Window # 01 
Tab 2 Window # 02 
Tab 2 Window # 03 
Tab 2 Window # 04 
Tab 2 Window # 05 
Tab 3 Window # 01 
Tab 3 Window # 02 



data 05 
data 06 
data 07 
data 08 
data 09 
data OA 
data 0B 
data OC 
dataOD 
dataOE 
data OF 
data 10 
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Game Number 0B Hex 


daw 04 


01 Hex 


data 05 


02 Hex 


data 06 


01 Hex 


data 07 


02 Hex 


data 08 


01 Hex 


data 09 


03 Hex 


data OA 


02 Hex 


data 0B 


03 Hex 


data 0C 


04 Hex 


data 0D 


00 Hex 


dataOE 


xx Hex 


data OF 


xx Hex 


data 10 


OO Hex 


1 


00 Hex 


data 53 



D. Response #2: Send a Ticket 

This response will be transmitted to the master pro- 
cessing unit 14 if the player has made a valid request for 
a play. In this case, the player must have credits, and 
must have pressed the Play pushbutton 166. 



Data Packet 




UnitNumber 


CMD byte 1 




Command 


CMD byte 2 


Send a Ticket: 


Response 02 


CMD byte 3 




Game Number (01.0C) 


data 04 



data 05 
data 06 
data 08 
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Data Packet 



data 53 
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E. Command #3: Receive a Validation Number 



F. Response #3: Send a Validation Number 

This command from the master processing unit 14 is This response is transmitted to the master processing 
generated in response to the slave terminal 16 sending 10 unit 14 if the player has made a valid request to cash out. 
Response #3-Request Validation Number. In this case, the player must have credits, and must have 



Data Packet 




Unit Number 


CMD byte 1 


Receive Valid. # 


Command 03 


CMD byte 2 


Response 


CMD byte 3 


0 BCD - 99 BCD 


THOUSANDS HUNDREDS 


data 04 


0 BCD - 99 BCD 


TENS UNITS 


data OS 


0 BCD • 99 BCD 


TENTHS HUNDREDTHS 


data 06 


0 Hex - 7F Hex 


Validation number 1 


data 07 




Validation number 2 


data 08 




Validation number 3 


data 09 




Validation number 4 


data OA 




Validation number 5 


data 0B 




Validation number 6 


dataOC 




Validation number 7 


dataOD 




Validation number 8 


data OE 




Validation number 9 


data OF 




Validation number 10 


data 10 




Validation number 11 


data 1 




1 


data 53 



If the master processing unit 14 sends the validation hit the Cash Out pushbutton 172. The response also 
number "0234AJUN93" for the amount of $10.50, the transmits the amount being cashed out. This lnforma- 
packet would appear as follows: tion is preferably used by the master processing unit 14 

* 35 to help create the validation number. 



Data Packet 




Unit Number 


CMD byte 1 




Command 03 


CMD byte 2 


Send Valid. # 


Response 03 


CMD byte 3 


0 BCD - 99 BCD 
0 BCD - 99 BCD 
0 BCD - 99 BCD 


THOUSANDS HUNDREDS 
TENS UNITS 
TENTHS HUNDREDTHS 

| data 07 

i data 08 

| data 09 

| data OA 

i 

data 53 


data 04 
data 05 
data 06 



BCD 


99 BCD 


00 Hex 


data 04 


BCD 


99 BCD 


10 Hex 


data 05 


BCD 


99 BCD 


50 Hex 


data 06 


Hex 


7F Hex 


30 Hex 


data 07 






32 Hex 


data 08 






33 Hex 


data 09 






34 Hex 


data OA 






41 Hex 


data 0B 






4A Hex 


data 0C 






55 Hex 


data 0D 






4E Hex 


dataOE 






39 Hex 


data OF 






33 Hex 


data 10 






20 Hex 


data 11 






i 

00 


data 53 
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Note that unused codes arc space filled (20H). 



G. Command #4: Receive Broadcast Information 
This command from the master processing unit 14 
will transmit a message to one or more of the slave 
terminals 16. It will request that a message number 
previously stored in the slave terminal 16 be displayed 
on the screen. Up to two parameters can be inserted into 
the message. Where the message itself contains "ESC 1" 
or "ESC 2" characters the parameters are inserted in 
those positions. Bytes not displayed are encoded as 00H. 



Data Packet 




Unit Number 


CMD byte 1 


Receive Message 


Command 05 


CMD byte 2 


Response 04 


CMD byte 3 


Hex - OA Hex 


Message Number (01 -OA) 


data 04 


Hex - 7F Hex 


ParamlByte 1 


data 05 
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-continued 


Data Packet 


" ParamlByte 2 


data 06 


ParamlByte 3 


data 07 


" ParamlByte 4 


data 08 


ParamlByte 5 


data 09 


ParamlByte 6 


data OA 


Param2Byte 1 


data OB 


Param2Byte 2 


data OC 


Param2Byte 3 


dataOD 


Param2Byte 4 


data OE 


Param2Byte 5 


data OF 


Param2Byte 6 


data 10 


1 

1 


data S3 



For example, if the Power Down time is five minutes 
ahead of when it actually will happen, then the follow- 
ing packet would be transmitted: 



10 



If message #5 was previously defined to be: 
"We have a winner of SESC 1 on MegaTab SESC 

2!!!" and the message to be displayed is: 
"We have a winner of $100 on MegaTab 25!!!" 
Then the following would be transmitted: 



IS 



00 Hex - FF Hex 


01 Hex 


data 01 




2CHex 


data 02 




1 


data 03 




I- 


data 04 




above is in seconds, 


data OS 




12CH = 300 = 5 minutes 


data 06 




1 


data 07 




1 


data 08 




1 


data 09 




1 


data OA 




1 


data 0B 




1 
1 


data 53 



05 Hex 


data 01 


31 Hex 


data 02 


30 Hex 


data 03 


30 Hex 


data 04 


00 Hex 


data 05 


00 Hex 


data 06 


00 Hex 


data 07 


32 Hex 


data 08 


35 Hex 


data 09 


21 Hex 


data OA 


21 Hex 


data 0B 


00 Hex 


dataOC 


1 

00 


data 53 



I. Command #6: Update Audit Information 

20 This command from the master processing unit 14 
requests the slave terminal 16 to update its audit infor- 
mation located in file AUDIT.PTG 182. 
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Data Packet 




Unit Number 


CMD byte 1 


Audit Information 


Command 06 


CMDbyte2 




Response 


CMD byte 3 




00 


data S3 



H. Command #5: Power Down Sequence 

This command from the master processing unit 14 
requests the slave terminal 16 to issue a "We are about 
to power down, please press cash out!" message. It will 
allow up to one parameter to be inserted into the mes- 40 
sage, e.g., the time until Power Down. 



J. Command #7: Requested Play Cannot Be 
Sent — Pool Empty 

This command from the master processing unit 14 
35 informs the slave terminal 16 that the last play request 



cannot be filled. 



Data Packet 



Data Packet 




Unit number 


CMD byte 1 


Power Down 


Command 06 


CMD byte 2 




Response 


CMD byte 3 



45 





Unit number 0 


CMD byte 1 


Deck Empty: 


Command 07 


CMD byte 2 




Response 


CMD byte 3 




Game Number (01.0C) 
1 

i 
1 
1 


data 04 
data OS 
data 06 
data 07 
data 53 



00 Hex - FF Hex 



Remaining (MSB-HI) 
Remaining (MSB-LO) 



above is in seconds, 
from 0000 to FFFF 



data 04 
data OS 
data 06 
data 07 
data 08 
data 09 
data OA 
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K. Response #4: Winning Play Ticket Just Displayed 

This response indicates to the master processing unit 
14 that a slave terminal 16 has just displayed a winning 
play. (It is up to the administrator to decide whether to 
display this information.) 



Data Packet 




Unit Number 


CMD byte 1 




Command 


CMD byte 2 


I've Won!!!: 


Response 04 


CMD byte 3 


00 BCD - 99 BCD 


THOUSANDS HUNDREDS 


data 04 


00 BCD - 99 BCD 


TENS UNITS 


data 05 


00 BCD - 99 BCD 


TENTHS HUNDREDTHS 


data 06 




| data 07 






data 53 





| data 0B 65 

Table 6 includes a list of the make and model of ele- 

J dala 53 ments employed in the presently preferred embodiment 

of the gaining system 10. 
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TABLE 6 




Ref. # 


Item 


Description 


Manufacturer 


20 


Local area 


Lantastic 


Artisoft, Inc. 




network 






44 


Keyboard 


Type 101 


Keytronics 


136 


Printer 


Laser Printer 


Epson America, 








Inc. 


112 


Printer 


40-column 


Star Micronics, 






printer 


Inc. 


(N/A) 


Bios type 


Basic I/O 


American 


System 


Megatrends, Inc. 


146 


Sound generator 


AY-3-8940 


Yamaha Corp. 


148 


Darlington Drive 


UNL-2003A 


Motorola, Inc. 


80 


LAN Interface 


Lantastic 


Artisoft, Inc. 


102 


LAN Interface 


Lantastic 


Artisoft, Inc. 


86 


Keyboard 


Type 101 


Keytronics 
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There has been described a computerized gaming 
system that provides fixed pools of games to be played 
by players on the system. According to a preferred 
embodiment of the invention, the gaming system is 20 
distributed between a central game processor, master 
processing units and slave terminals. The fixed pools of 
game plays are created at the central game processor 
and downloaded to the master processing units upon 
request. Through the slave terminals, players can pur- 
chase game plays from each fixed pool of plays received 
and stored at the master processing unit to which the 
slave is attached. 



25 



a master processing unit, the master processing unit 
operative to distribute game plays from a finite 
pool of game plays 

a memory device coupled to the master processing 
unit, the memory device operative to store at least 
one finite pool of game plays, each finite pool con- 
taining a predefined number of winning and load- 
ing play records wherein each game play record 
contains an indication of whether the particular 
play constitutes a winning or losing play and the 
amount won; 

a communication interface coupled to the master 
processing unit; 

a plurality of slave terminals, each slave terminal 
coupled to the communication interface to receive 
game play records in response to a game play re- 
quest received from a player; 

a plurality of player-controlled selection devices, 
each player-controlled selection device coupled to 
a slave terminal and operative to transmit game 
play requests from the player to the master process- 
ing unit; and 

a plurality of output devices, each output device 
coupled to a slave terminal and operative to com- 
municate to the player the receipt of a winning or 
losing play and the amount won. 
2. The game system network defined in claim 1, 
wherein a plurality of players can simultaneously oper- 
ate the player-controlled selection devices provided on 



In the preferred embodiment, a game play cone olt ^ Fmj „,-^ r ._.. 

sponds to a video representation of a paper pull-tab the p i ura iit y of slave terminals to request game play 
lottery ticket. As in the paper pull-tab lottery game, a 
predetermined number of winning and losing tickets is 
established for each pool of game plays. Also, a prede- 
termined dollar value for winning plays is included with 
each game pool. According to the invention, therefore, 
each player can purchase game plays from the entire 
fixed pool being stored at the master processing unit to 
which a slave terminal is connected. Since multiple 
slave terminals are contemplated for connection to each 
master processing unit, a single player may compete 
against other players located at similar slave terminals 
to purchase as many of the winning tickets in each fixed 
pool as possible. 

The gaming system described above thus combines 4J 
the advantages of paper lottery and wagering games 
with the popularity and attractiveness of the video 
game. As described, each player can compete directly 
with other players for the purchase of winning plays, 
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records from the entire fixed pool of game play records 
stored in the memory device. 

3. The gaming system network defined in claim 1, 
wherein the communication interface comprises a local 
area network. 

4. The gaming system network defined in claim 1, 
wherein each slave terminal further comprises a pro- 
cessing element, a display, a local area network inter- 
face, and a wager deposit device. 

5. The gaming system network defined in claim 4, 
wherein the processing element is coupled to the play- 
er-controlled selection device and comprises a personal 
computer. 

6. The gaming system network defined in claim 1, 
wherein the player-controlled selection device com- 
prises a push-button. 

7. The gaming system network defined in claim 1, 
wherein the master processing unit comprises a per- 



thus providing an element of competition over the prior jq sonal computer, 
paper pull-tab lottery games. Since it is contemplated 8. The gaming system network defined in claim 1, 
that slave terminals may be located either within the . wherein the master processing unit comprises means for 
same location or remotely from one another, players mamtaining a record of the number of game play re- 
can also compete with other players both locally and cords selected at each slave tenninal from each finite 
across great distances. The excitement, sounds and vi- 55 pool of game play records and the number of game play 
sual display inherent in a video game provides further records remaining in each finite pool of game play re- 
attraction of the computer gaming system over the cords stored at the memory device, 
prior paper lottery type games. 9. The gaming system network defined in claim 1, 

It is to be understood that a wide range of changes further comprising a central game processor for gener- 
and modifications to the embodiments described above 60 ating the at least one finite pool of game plays, and a 



will be apparent to those skilled in the art and are con- 
templated. It is, therefore, intended that the foregoing 
detailed description be regarded as illustrative rather 
than limiting, and that it be understood that it is the 
following claims, including all equivalents, that are 65 
intended to define the spirit and scope of this invention. 
We claim: 

1. A gaming system network comprising: 



communication interface coupled between the master 
processing unit and central game processor and opera- 
tive to supply for each finite pool of game plays the 
predefined number of winning and losing play records 
to the master processing unit. 

10. The gaming system network defined in claim 9, 
wherein the central game processor comprises means 
for supplying a new finite pool of game plays to the 
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master processing unit upon exhaustion of each finite 
pool of game play records stored at the memory device. 

11. The gaming system network defined in claim 9, 
wherein the central game processor comprises means 
for maintaining a record of the number of game plays 5 
remaining in each finite pool of game plays and the 
number of winning and losing play records remaining in 
each finite pool of game plays. 

12. The gaming system network defined in claim 9, 
wherein the communication interface comprises a 10 
modem. 

13. The gaming system network defined in claim 9, 
wherein the central game processor further comprises a 
personal computer. 

14. The gaming system network defined in claim 1, 15 
wherein each game play record comprises an electroni- 
cally-simulated pull-tab lottery ticket. 

15. A gaming system network comprising: 

master means for distributing game plays from a fixed 
- pool of game plays; 20 

means for storing at least one fixed pool of game 
plays, coupled to the master means, each fixed pool 
having a predetermined number of winning and 
losing game play records wherein each game play 
record contains an indication of whether the partic- 25 
ular play constitutes a winning or losing play and 
the amount won; 

interface means, coupled to the master means, for 
communicating game play records from the means 
for storing in response to game play requests; 30 

a plurality of slave means, coupled to the interface 
means, for receiving game play records from the 
master means in response to game play requests 
received from a player; 

player-controlled selection means, coupled to a slave 35 
means, for transmitting game play requests from 
the player to the master means; and 

output means, coupled to a slave means, for commu- 
nicating to the player the receipt of a winning or 
losing play and the amount won. 40 

16. A gaming system network comprising: 

a master processing unit, the master processing unit 
operative to distribute game play records from a 
finite pool of game play records; 

a memory device coupled to the master processing 45 
unit, the memory device operative to store at least 
one finite pool of game play records, each finite 
pool of game play records containing a predefined 
number of winning and losing play records 
wherein each game play record contains an indica- 50 
tion of whether the particular game play consti- 
tutes a winning or losing play and the amount won; . 

a communication interface for coupling the slave 
terminals on line to the master processing unit; 

55 



a plurality of slave terminals, each slave terminal 
coupled to the communication interface to receive 
game play records from the memory device in 
response to a game play request received from a 
player; 

a plurality of player-controlled selection devices, 
each player-controlled selection device coupled to 
a slave terminal and operative to transmit game 
play requests from the player to the master process- 
ing unit; and 

a plurality of output devices, each output device 
coupled to a slave terminal and operative to com- 
municate to the player the receipt of a winning or 
losing play and the amount won. 

17. The gaming system network defined in claim 16, 
wherein the communication interface comprises a local 
area network. 

18. A gaming system network comprising: 
a central game processor for generating a plurality of 

finite pools of game plays, each finite pool having a 
predetermined number of winning and losing game 
play records, each game play record comprising an 
indication of whether the particular play consti- 
tutes a winning play and the amount won; 
a plurality of master processing units, each master 
processing unit coupled to the central game proces- 
sor through a first communication interface and 
operative to receive the game play records from 
the central game processor; 
a memory device coupled to each master processing 
unit, the memory device operative to store at least 
one finite pool of game play records, each finite 
pool of game play records containing a predefined 
number of winning and losing game play records 
wherein each game play record contains an indica- 
tion of whether the particular play constitutes a 
winning play and the amount won; 
a second communication interface coupled to each 

master processing unit; 
a plurality of slave terminals, each slave terminal 
coupled to the second communication interface to 
receive game play records from the master pro- 
cessing unit in response to a game play request 
received from a player; 
a plurality of player-controlled selection devices, 
each player-controlled selection device coupled to 
a slave terminal and operative to transmit game 
play requests from the player to the master process- 
ing unit; and 

a plurality of output devices, each output device 
coupled to a slave terminal and operative to com- 
municate to the player the receipt of a winning play 
and the amount won. 
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